آموزش [جدید] متخصص مهندسی DevOps تایید شده توسط مایکروسافت - آخرین آپدیت

پوشش دقیق دامنه‌های آزمون

این دوره آزمون‌های تمرینی دقیقاً بر اساس نقشه راه (Blueprint) رسمی مایکروسافت ساختار یافته است. سوالات در چهار دامنه اصلی تقسیم شده‌اند تا آمادگی متوازن شما تضمین شود:

• یکپارچه‌سازی و تحویل مداوم (CI/CD) (۲۵٪)

  • طراحی Azure Pipelines برای انتشارهای چند مرحله‌ای و استقرار‌های پیچیده.

  • پیاده‌سازی اتوماسیون ساخت (Build) و انتشار (Release) با استفاده از نحو YAML.

  • یکپارچه‌سازی ابزارهای شخص ثالث مانند GitHub و Jenkins در اکوسیستم Azure DevOps.

  • مدیریت متغیرهای خط لوله، اسرار امن، محیط‌ها و تاییدات دستی.

• زیرساخت به عنوان کد (IaC) و مدیریت پیکربندی (۲۵٪)

  • نویسندگی، ماژولار کردن و استقرار ARM templates و ماژول‌های Bicep.

  • به‌کارگیری Terraform برای توزیع پیش‌بینی‌پذیر منابع Azure و مدیریت چرخه حیات آن‌ها.

  • پیکربندی مدیریت وضعیت (State Management)، بک‌اندهای دوردست و شناسایی تغییرات ناخواسته (Configuration Drift).

  • پیاده‌سازی جریان‌های کاری مدیریت پیکربندی با Ansible یا Chef.

• امنیت، انطباق و حاکمیت (۲۵٪)

  • پیاده‌سازی حاکمیت خودکار از طریق Azure Policy و Azure Blueprints.

  • مدیریت و تزریق امن اسرار با استفاده از Azure Key Vault در خط لوله‌ها.

  • اعمال کنترل دسترسی مبتنی بر نقش (RBAC) دقیق در پروژه‌ها و تیم‌های DevOps.

  • یکپارچه‌سازی ابزارهای امنیتی خودکار، تحلیل ایستا کد (SAST) و اسکن کانتینرها.

• مانیتورینگ، بازخورد و بهینه‌سازی (۲۵٪)

  • پیکربندی مشاهده‌پذیری عمیق با استفاده از Azure Monitor، Log Analytics و Application Insights.

  • راه‌اندازی هشدارها بر اساس آستانه (Threshold) و اصلاحات خودکار (Self-healing).

  • تحلیل گلوگاه‌های عملکرد خط لوله و اجرای استراتژی‌های بهینه‌سازی هزینه.

  • پیاده‌سازی معیارهای سلامت انتشار، نمایش تدریجی (Progressive Exposure) و حلقه‌های بازخورد کاربر.

توضیحات دوره

کسب مدرک Microsoft Certified: DevOps Engineer Expert یکی از قطعی‌ترین راه‌ها برای اثبات توانایی شما در طراحی و اجرای استراتژی‌های تحویل Cloud-native است. با این حال، آزمون واقعی بیش از دانش مفهومی نیاز دارد؛ این آزمون از شما می‌خواهد سناریوهای پیچیده معماری را تحلیل کنید، پیکربندی‌های خط لوله را دیباگ کنید و در محدودیت‌های زمانی شدید، تصمیمات حیاتی حاکمیتی بگیرید.

من این بانک سوالات تمرینی را برای پر کردن شکاف بین مطالعه تئوری و قبولی در آزمون طراحی کرده‌ام. به جای سوالات کلی، این تست‌های هدفمند درک عملی شما را از نحوه یکپارچه‌سازی Azure DevOps با GitHub، Terraform، ابزارهای امنیتی و مجموعه‌های مانیتورینگ به چالش می‌کشد. من برای هر سوال توضیحات مفصلی نوشته‌ام که چرا رویکرد صحیح درست است و دقیقاً چرا گزینه‌های جایگزین در سناریوهای دنیای واقعی شکست می‌خورند.

با تحلیل این سناریوها، شما غریزه‌ای را توسعه می‌دهید که بتوانید گزینه‌های گمراه‌کننده را شناسایی کرده و با اطمینان، کارآمدترین و امن‌ترین انتخاب‌های معماری را برگزینید. این مسیر آموزشی کاملاً بر ایجاد استقامت و شفافیت فنی متمرکز است تا بتوانید با اعتماد به نفس کامل وارد مرکز آزمون شده و در اولین تلاش موفق شوید.

نمونه پیش‌نمایش سوالات تمرینی

سوال ۱: طراحی خط لوله‌های CI/CD امن

تیم شما از یک خط لوله YAML چند مرحله‌ای در Azure DevOps برای استقرار یک اپلیکیشن وب در Azure App Service استفاده می‌کند. مرحله استقرار تولید (Production) باید به یک رشته اتصال دیتابیس (Connection String) دسترسی داشته باشد که به صورت امن در Azure Key Vault ذخیره شده است. معماری باید اصل «حداقل دسترسی» را اجرا کرده و از هرگونه درج سخت‌افزاری (Hardcoded) اعتبارنامه‌ها در مخزن خط لوله جلوگیری کند.

چگونه باید خط لوله و معماری Azure را پیکربندی کنید تا این راز (Secret) در زمان اجرا به صورت امن بازیابی شود؟

• گزینه‌ها:

  • الف. ارجاع مستقیم به راز در فایل YAML با استفاده از نحو استاندارد $(db-secret) پس از اعطای دستی نقش Key Vault Secrets Officer به حساب مدیر پروژه Azure DevOps.

  • ب. پیکربندی یک گروه متغیر (Variable Group) متصل به نمونه Azure Key Vault، مجاز کردن خط لوله برای استفاده از این گروه متغیر و ارجاع به متغیر در مرحله استقرار.

  • ج. افزودن یک تسک Azure PowerShell که یک اسکریپت لاگین را با استفاده از اعتبارنامه سخت‌افزاری Service Principal اجرا کند تا راز را از Key Vault به یک متغیر محیطی منتقل کند.

  • د. استفاده از تسک Azure Key Vault در شغل استقرار، تنظیم آن برای دانلود تمام اسرار و استفاده از یک Agent میزبانی‌شده (Self-hosted) با یک فایل متنی محلی حاوی کلیدهای دسترسی Key Vault.

  • ه. متصل کردن Azure Key Vault به یک گردش کار GitHub Actions، خروجی گرفتن از راز به صورت رشته متنی ساده (Plain-text) و ارسال آن به Azure Pipeline از طریق یک Webhook.

  • و. ایجاد یک Azure Storage Blob عمومی حاوی رشته راز و افزودن یک تسک دستور curl در خط لوله برای دانلود مستقیم فایل در هنگام اجرای استقرار.

• پاسخ صحیح: ب

• توضیحات مفصل:

  • چرا گزینه ب صحیح است: متصل کردن یک گروه متغیر به Azure Key Vault به Azure DevOps اجازه می‌دهد تا اسرار را به صورت امن با استفاده از اتصال سرویس ARM زیربنایی به متغیرهای خط لوله نگاشت کند. این رویکرد به اصل حداقل دسترسی احترام می‌گذارد، احراز هویت را به صورت بومی مدیریت می‌کند، اسرار را از کنترل نسخه دور نگه می‌دارد و خروجی را به طور خودکار در لاگ‌های خط لوله ماسک (مخفی) می‌کند.

  • چرا گزینه الف غلط است: ارجاع مستقیم بدون اتصال از طریق گروه متغیر یا تسک صریح Key Vault باعث می‌شود خط لوله به دنبال یک متغیر استاندارد و غیرموجود بگردد. علاوه بر این، نقش‌ها باید به Service Principal متصل به اتصال سرویس اعطا شوند، نه به حساب مدیر پروژه کاربر.

  • چرا گزینه ج غلط است: درج سخت‌افزاری اعتبارنامه‌های Service Principal در اسکریپت یا فایل YAML هدف استفاده از Azure Key Vault را کاملاً از بین می‌برد و ریسک امنیتی بحرانی نشت اعتبارنامه‌ها را به مخزن Git وارد می‌کند.

  • چرا گزینه د غلط است: ذخیره کلیدهای دسترسی Key Vault در یک فایل متنی محلی روی یک Agent میزبانی‌شده، در صورت به خطر افتادن ماشین میزبان، یک آسیب‌پذیری امنیتی عظیم ایجاد می‌کند.

  • چرا گزینه ه غلط است: ارسال اسرار به صورت متن ساده و بدون ماسک از طریق Webhookها، داده‌های حساس را در حین انتقال در معرض دید قرار داده و سوابق متنی قابل مشاهده در لاگ‌ها ایجاد می‌کند که یک تخلف جدی در انطباق (Compliance) است.

  • چرا گزینه و غلط است: قرار دادن رشته‌های اتصال دیتابیس حساس در یک Blob ذخیره‌سازی عمومی، به هر کسی در اینترنت اجازه می‌دهد اعتبارنامه‌های بک‌اند شما را ببیند که یک خطر امنیتی شدید و غیرقابل قبول است.

سوال ۲: زیرساخت به عنوان کد و مدیریت وضعیت (State Management)

شما یک محیط زیرساختی سازمانی Azure را با استفاده از Terraform مدیریت می‌کنید. چندین توسعه‌دهنده روی یک کدبیس همکاری می‌کنند و متوجه می‌شوید که استقرار‌های همزمان (Concurrent) گاهی باعث خرابی فایل وضعیت (State File) می‌شود. علاوه بر این، تغییراتی که به صورت دستی در پورتال Azure اعمال شده‌اند منجر به انحراف پیکربندی (Configuration Drift) شده است.

کدام ترکیب از مراحل پیکربندی، مشکلات همزمانی را حل کرده و به شما اجازه می‌دهد انحراف زیرساختی را به دقت شناسایی کنید؟

• گزینه‌ها:

  • الف. ذخیره فایل وضعیت Terraform به صورت محلی در یک درایو شبکه مشترک، تنظیم یک cron job برای کپی کردن متقابل آن و تکیه بر ارتباط توسعه‌دهندگان برای جلوگیری از اجراهای همزمان.

  • ب. کامیت کردن فایل terraform.tfstate مستقیماً در مخزن Git، استفاده از پالیسی‌های استاندارد شاخه برای جلوگیری از Pull Requestهای متضاد و استفاده از git diff برای بررسی انحراف زیرساخت.

  • ج. پیکربندی یک بک‌اند وضعیت دوردست (Remote State Backend) با استفاده از یک Azure Storage Account با Blob Storage، فعال‌سازی قفل وضعیت بومی (Native State Locking) و اجرای terraform plan برای شناسایی انحراف.

  • د. پیاده‌سازی Azure Blueprints برای قفل کردن تمام منابع، استفاده از یک ARM template برای بازنویسی تغییرات وضعیت محلی در هر ساعت و اجرای انحصاری terraform refresh.

  • ه. انتقال کامل فایل‌های Terraform به یک Ansible playbook سفارشی، اجرای پلی‌بوک‌ها با فعال بودن پرچم check و ذخیره معیارهای وضعیت در یک محیط Azure Log Analytics.

  • و. پیکربندی بک‌آپ فایل وضعیت محلی روی یک درایو USB رمزنگاری شده، کپی دستی ورودی‌های وضعیت در لاگ‌های Azure Monitor و استفاده از هشدارهای Azure Advisor برای شناسایی هرگونه تغییر در منابع.

• پاسخ صحیح: ج

• توضیحات مفصل:

  • چرا گزینه ج صحیح است: استفاده از بک‌اند Azure Storage، مدیریت متمرکز وضعیت را به صورت بومی مدیریت می‌کند. بک‌اند دوردست Azure به طور خودکار از مکانیسم‌های اجاره Blob برای اعمال قفل وضعیت در حین اجرا استفاده می‌کند و از نوشتن‌های همزمان و خرابی وضعیت جلوگیری می‌کند. اجرای terraform plan وضعیت لحظه‌ای را با فایل وضعیت شما تطبیق داده و هرگونه اختلاف یا انحراف دستی خارج از Terraform را برجسته می‌کند.

  • چرا گزینه الف غلط است: درایوهای محلی مشترک از قفل فایل در سطح API پشتیبانی نمی‌کنند و وضعیت را در برابر Race Conditions و تغییرات همزمان که فایل را خراب می‌کنند، بسیار آسیب‌پذیر می‌کنند.

  • چرا گزینه ب غلط است: ذخیره فایل‌های وضعیت در مخزن Git، داده‌های حساس (مانند رمزهای عبور متن ساده یا کلیدهای تولید شده) را در تاریخچه کنترل نسخه افشا می‌کند. همچنین از اجرای همزمان Apply بین توسعه‌دهندگانی که روی یک شاخه کار می‌کنند جلوگیری نمی‌کند.

  • چرا گزینه د غلط است: قفل‌های منابع Azure Blueprints از حذف یا تغییر تصادفی توسط کاربران جلوگیری می‌کنند، اما مکانیسم‌های داخلی همزمانی یا ردیابی وضعیت Terraform را حل نمی‌کنند.

  • چرا گزینه ه غلط است: انتقال کامل به Ansible چارچوب ابزاری را تغییر می‌دهد اما نیازمندی‌های اصلی وضعیت Terraform را برطرف نمی‌کند. Ansible وضعیت منابع را مشابه مدل Declarative ترافورم برای تحلیل انحراف نگاشت نمی‌کند.

  • چرا گزینه و غلط است: ذخیره‌سازی روی سخت‌افزار محلی و کپی دستی لاگ‌ها ناامن است، برای همکاری تیمی کاملاً ناکارآمد است و هیچ قفل خودکار یا موتور مقایسه‌ای زنده‌ای ارائه نمی‌دهد.

سوال ۳: مشاهده‌پذیری و اصلاح خودکار (Automated Remediation)

یک اپلیکیشن میکروسرویس میزبانی شده در Azure Kubernetes Service (AKS) دچار نشت حافظه (Memory Leak) دوره‌ای می‌شود که در ساعات پیک ترافیک باعث کرش کردن کانتینرها می‌گردد. شما باید استراتژی مانیتورینگی ایجاد کنید که معیارهای سفارشی اپلیکیشن را ثبت کند، روندهای لحظه‌ای را نمایش دهد و یک جریان کاری خودکار را برای اطلاع‌رسانی به تیم مهندسی و در عین حال ری‌استارت کردن متین (Graceful Restart) پادهای مشکل‌دار فعال کند.

کدام معماری به بهترین وجه این نیازمندی‌های عملکردی و عملیاتی را برآورده می‌کند؟

• گزینه‌ها:

  • الف. پیکربندی اپلیکیشن برای نوشتن Error Dumpها در ذخیره‌ساز محلی کانتینر و ساخت یک اسکریپت Shell که در یک حلقه مداوم داخل Node اجرا شود تا هنگام پر شدن فضا، لاگ‌ها را حذف کند.

  • ب. یکپارچه‌سازی Application Insights SDK در کد میکروسرویس، استریم کردن معیارها به یک محیط Azure Log Analytics، تنظیم یک هشدار معیار در Azure Monitor و متصل کردن یک Action Group که یک Azure Function یا Logic App را فعال کند.

  • ج. تنظیم توصیه‌های Azure Advisor برای شناسایی مشکلات کلاستر، پیکربندی یک هشدار ایمیلی استاندارد در پورتال صورت‌حساب Azure و دستور به مهندسان On-call برای ری‌استارت دستی Nodeهای AKS.

  • د. استقرار یک میزبان Azure Bastion برای اتصال مستقیم به Virtual Machine Scale Sets زیربنایی AKS، اجرای دستی دستورات top از ترمینال و کشتن پروسه‌ها هنگام افزایش مصرف حافظه.

  • ه. تکیه کامل بر لاگ‌های Azure Resource Health برای مانیتور کردن پروفایل حافظه هر پاد و نوشتن یک Azure Automation Runbook که در صورت بروز خطا، کل Resource Group مربوط به AKS را حذف کند.

  • و. پیکربندی هشدار Azure Activity Log برای فعال شدن هر بار که کاربر داشبورد اپلیکیشن را مشاهده می‌کند و متصل کردن یک Action Group که به طور خودکار سطح اشتراک Azure را ارتقا دهد.

• پاسخ صحیح: ب

• توضیحات مفصل:

  • چرا گزینه ب صحیح است: یکپارچه‌سازی Application Insights تله‌متری عمیق در سطح اپلیکیشن و معیارهای سفارشی را ثبت می‌کند. استریم این داده‌ها به Log Analytics اجازه می‌دهد پرس‌وجوهای پیچیده بنویسید و روندهای تاریخی را تحلیل کنید. هشدارهای Azure Monitor فوراً به عبور از آستانه‌های خاص واکنش نشان می‌دهند و Action Group اجازه می‌دهد اصلاحات خودکار (از طریق Azure Function یا Logic App) را برای اجرای ری‌استارت پاد و اطلاع‌رسانی به تیم مهندسی سازماندهی کنید.

  • چرا گزینه الف غلط است: نوشتن لاگ‌ها در ذخیره‌ساز موقت (Ephemeral) کانتینر، فضای دیسک را مصرف کرده، فشار روی Node را افزایش می‌دهد و باعث می‌شود تمام داده‌های تشخیصی هنگام کرش کانتینر کاملاً ناپدید شوند.

  • چرا گزینه ج غلط است: Azure Advisor توصیه‌های بهینه‌سازی سطح بالا برای هزینه، امنیت و قابلیت اطمینان ارائه می‌دهد، اما یک ابزار مانیتورینگ لحظه‌ای یا هشدار برای شناسایی افزایش ناگهانی حافظه در سطح اپلیکیشن نیست.

  • چرا گزینه د غلط است: مشاهده دستی از طریق Azure Bastion در مقیاس بالا غیرقابل مدیریت است، بهره‌وری عملیاتی را از بین می‌برد و برای حادثه‌ای که نیاز به اصلاح خودکار فوری دارد، به دخالت انسانی تکیه می‌کند.

  • چرا گزینه ه غلط است: Resource Health در دسترس بودن زیرساخت پلتفرم Azure را مانیتور می‌کند، نه عملکرد کد داخلی یا نشت حافظه در پادهای کوبرنتیز. حذف کل Resource Group باعث قطع کامل دسترسی تولید می‌شود.

  • چرا گزینه و غلط است: Activity Logها اقدامات سطح کنترل (Control-plane) مدیریتی را ردیابی می‌کنند، نه عملکرد اپلیکیشن. ارتقای سطح صورت‌حساب، مشکل نشت حافظه در کد اپلیکیشن را حل نمی‌کند.

• به آکادمی آزمون‌های تمرینی خوش آمدید تا شما را برای آزمون Microsoft Certified: DevOps Engineer Expert آماده کنیم.

• می‌توانید آزمون‌ها را هر تعداد بار که بخواهید تکرار کنید.

• این یک بانک سوالات جامع و اورجینال است.

• در صورت داشتن سوال، از پشتیبانی مدرسان بهره‌مند می‌شوید.

• هر سوال دارای یک توضیح تشریحی مفصل است.

• با اپلیکیشن Udemy کاملاً با موبایل سازگار است.

امیدوارم تا الان متقاعد شده باشید! سوالات بسیار بیشتری در داخل دوره وجود دارد.